Risk management system

ABSTRACT

An automated method and system ( 100 ) for risk analysis, management and optimization for a plurality of commercial enterprises.

This application is a divisional of application Ser. No. 10/329,172filed Dec. 23, 2002 the disclosure of which is incorporated herein byreference. The subject matter of this application is also related to thesubject matter of U.S. Pat. No. 5,615,109 for “Method of and System forGenerating Feasible, Profit Maximizing Requisition Sets”, by Jeff S.Eder, the disclosure of which is incorporated herein by referenceapplication Ser. No. 10/329,172 was a divisional of U.S. patentapplication Ser. No. 09/688,983 filed Oct. 17, 2000 the disclosure ofwhich is incorporated herein by reference. The subject matter of thisapplication is also related to the subject matter of U.S. patentapplication Ser. No. 09/994,740 filed Nov. 28, 2001, U.S. patentapplication Ser. No. 10/036,522 filed Jan. 7, 2002, U.S. patentapplication Ser. No. 10/046,094 filed Jan. 16, 2002, U.S. patentapplication Ser. No. 10/166,758 filed Jun. 12, 2002, U.S. patentapplication Ser. No. 10/747,471 filed Dec. 29, 2003, U.S. patentapplication Ser. No. 10/821,504 filed Apr. 9, 2004 and U.S. patentapplication Ser. No. 11/142,785 filed May 31, 2005 the disclosures ofwhich are all also incorporated herein by reference.

BACKGROUND OF THE INVENTION

This invention relates to a method of and system for risk management forone or more commercial enterprises.

Insurance and most financial services are generally delivered in amanner that is very cumbersome. A system that would enable financialservice firms to provide financial “products” like insurance,derivatives, foreign exchange, capital and credit tailored to thespecific situation on a “just-in-time” would clearly be beneficial.

One of the biggest problems with achieving this goal has been that therehas been no agreed upon method for analyzing risk, liquidity and foreignexchange requirements and for communicating that information tofinancial service firms. It is worth noting at this point that while XMLis widely touted as a panacea for inter-firm communication it is onlyuseful in establishing the language for the communication—not thesubstance of what is being communicated. To satisfy all the potentialproviders of financial services, the substance of the communicationregarding risk, liquidity and foreign exchange requirements would haveto overcome the limitations of traditional systems and xml.

In light of the preceding discussion, it is clear that it would bedesirable to have an automated, real time system that could identify thefull spectrum of risk transfer (and liquidity) needs for an enterprisein a way that that would allow financial service firms to provide “justin time” and/or real time financial products and services in a mannerthat is customized to the exact needs of the customers using the system.

SUMMARY OF THE INVENTION

It is a general object described herein to provide a novel and usefulsystem for the collaborative, on-line development and delivery ofcustomized risk transfer programs that overcomes the limitations anddrawbacks of the existing art.

The information regarding the risk transfer needs for each customerusing the system is continuously developed and communicated in summaryformat to the operator of the system described herein (such as aninsurance company or bank) that analyzes the information for eachcustomer to:

1) Arrange swaps of risk, between customers with complementary,offsetting needs (for a fee);

2) Arrange for risk transfers for a larger fee as required to meet theneeds of each customer using the system and the profit goals (andreserve requirements) of the firm operating the system; and

3) Complete the swaps and risk transfers that have been arranged inaccordance with customer instructions.

To provide an integrated system for transferring risk, the systemdescribed herein goes on to analyze the information provided by eachenterprise and the financial status of firm operating the system(hereinafter, the system operator) to determine if standby credit linesand/or re-insurance are required. If either of these “back-up” (akacontingent) facilities for capital are required, then the appropriateamount of standby credit and/or reinsurance is determined by the systemdescribed herein.

By eliminating many of the gaps in information available to personnel inthe enterprise and the system, the system described herein enables thejust-in-time provision of financial service products and services suchas risk transfer that are tailored to the exact needs of the enterprise.The electronic linkage also eliminates the time lag that prevents manyfrom companies from obtaining the risk reduction products they need

BRIEF DESCRIPTION OF DRAWINGS

These and other objects, features and advantages described herein willbe more readily apparent from the following description of the preferredembodiment of the invention in which:

FIG. 1 is a block diagram showing the major processing steps describedherein;

FIG. 2 is a diagram showing the files or tables in the applicationdatabase (50) described herein that are utilized for data storage andretrieval during the processing in the innovative risk transfer system;

FIG. 3 is a block diagram of an implementation described herein;

FIG. 4 is a diagram showing the data windows that are used for receivinginformation from and transmitting information to the customer (20)during system processing;

FIG. 5, is block diagrams showing the sequence of steps in the presentinvention used for specifying system settings and for initializing andoperating the data bots that extract, aggregate, store and manipulateinformation utilized in system processing from: the basic financialsystem, advanced financial system, customers and external databases; and

FIG. 6 is a block diagram showing the sequence in steps in the presentinvention used in the collaborative, on-line development and delivery ofcustomized risk transfer programs.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

FIG. 1 provides an overview of the processing completed by the systemfor the collaborative, on-line development and delivery of customizedrisk transfer programs. In accordance with the present invention, anautomated method of and system (100) for collaborative, on-linedevelopment and delivery of customized risk transfer programs isprovided. Processing starts in this system (100) with the specificationof system settings and the initialization and activation of softwaredata “bots” (200) that extract, aggregate, manipulate and store theinternal data, external data, customer (20) input and a customerfinancial model required for completing system processing. The data fromexternal databases is used to analyze generic event risks and prices oninvestments for the asset classes and contingent liabilities specifiedby the system operator (21). In the preferred embodiment, the customerfinancial model is created using the system described in the crossreferenced application Ser. No. 10/747,471 as required to identify theimpact of the different elements of value, external factors and risks oncustomer financial performance and value. However, any other method orsystem for developing this data could be used to the same effect. Allrequired data is extracted via a network (45) from a basic financialsystem database (5), an external database (25), an advanced financesystem database (30) and a customer database (35). These informationextractions and aggregations may be influenced by a system operator (21)through interaction with a user-interface portion of the applicationsoftware (700) that mediates the display, transmission and receipt ofall information to and from browser software (800) such as the MicrosoftInternet Explorer or Netscape Navigator in an access device (90) such asa phone or personal computer that the customer (20) or system operatorinteract with. While only one basic financial system database (5),external database (25), advanced finance system database (30) andcustomer database (35) is shown in FIG. 1, it is to be understood thatthe system (100) can extract data from an unlimited number of databasesand customers via the network (45). It also to be understood that thecustomer (20) and the system operator (21) can operate separate accessdevices (90). It should also be understood that it is possible tocomplete a bulk extraction of data from each database (5, 25, 30 and 35)via the network (45) using data extraction applications beforeinitializing the data bots. The data extracted in bulk could be storedin a single datamart or data warehouse where the data bots could operateon the aggregated data.

All extracted information is stored in a file or table (hereinafter,table) within an application database (50) as shown in FIG. 2. Theapplication database (50) contains tables for storing input, extractedinformation and system calculations including an xml profile table(140), a bot date table (141), a customer table (142), a risk productstable (143), a swaps table (144), a customer profile table (145), anexchange payout history table (146), an generic risk table (147), aliability scenario table (148), an asset position table (149), anexternal database table (150), an asset forecasts table (151), an assetcorrelation table (152), an scenario table (153), an exchange simulationtable (154), a contingent capital table (155), an optimal exchange mixtable (156) and an exchange premium history table (157) a systemsettings table (158), a metadata mapping table (159), a conversion rulestable (160), a basic financial system table (161) and an advancedfinance system table (162). Other combinations of tables and files canbe used to the same effect. The application database (50) can optionallyexist on a hard drive, a datamart, data warehouse or departmentalwarehouse. The system described herein has the ability to accept andstore supplemental or primary data directly from user input, a datawarehouse or other electronic files in addition to receiving data fromthe customer databases described previously.

As shown in FIG. 3, the preferred embodiment described herein is acomputer system (100) illustratively comprised of a user-interfacepersonal computer (110) connected to an application-server personalcomputer (120) via a network (45). The application server personalcomputer (120) is in turn connected via the network (45) to adatabase-server personal computer (130). The user interface personalcomputer (110) is also connected via the network (45) to an internetbrowser appliance (90) that contains browser software (800) such asMicrosoft Internet Explorer or Netscape Navigator.

The database-server personal computer (130) has a read/write randomaccess memory (131), a hard drive (132) for storage of the applicationdatabase (50), a keyboard (133), a communications bus card containingall required adapters and bridges (134), a display (135), a mouse (136)and a CPU (137).

The application-server personal computer (120) has a read/write randomaccess memory (121), a hard drive (122) for storage of thenon-user-interface portion of the enterprise portion of the applicationsoftware (200 and 300) described herein, a keyboard (123), acommunications bus containing all required adapters and bridges (124), adisplay (125), a mouse (126), a CPU (127) and a printer (128). Whileonly one client personal computer is shown in FIG. 3, it is to beunderstood that the application-server personal computer (120) can benetworked to fifty or more client personal computers (110) via thenetwork (45). The application-server personal computer (120) can also benetworked to fifty or more server, personal computers (130) via thenetwork (45). It is to be understood that the diagram of FIG. 3 ismerely illustrative of one embodiment described herein as the system(100) and application software (200, 300 and 700) could reside on asingle computer or any number of computers that are linked togetherusing a network. In a similar manner the system operator (21) and/or thecustomer (20) could interface directly with one or more of the computersin the system (100) instead of using an access device (90) with abrowser (800) as described in the preferred embodiment.

The user-interface personal computer (110) has a read/write randomaccess memory (111), a hard drive (112) for storage of a clientdata-base (49) and the user-interface portion of the applicationsoftware (700), a keyboard (113), a communications bus containing allrequired adapters and bridges (114), a display (115), a mouse (116), aCPU (117) and a printer (118).

The application software (200, 300 and 700) controls the performance ofthe central processing unit (127) as it completes the calculationsrequired to support the collaborative development and implementation ofa risk transfer program. In the embodiment illustrated herein, theapplication software program (200, 300 and 700) is written in acombination of C++ and Visual Basic® although other languages can beused to the same effect. The application software (200, 300 and 700) canuse Structured Query Language (SQL) for extracting data from thedifferent databases (5, 25, 30 and 35). The customer (20) and systemoperator (21) can optionally interact with the user-interface portion ofthe application software (700) using the browser software (800) in thebrowser appliance (90) to provide information to the applicationsoftware (200, 300 and 700) for use in determining which data will beextracted and transferred to the application database (50) by the databots.

User input is initially saved to the client database (49) before beingtransmitted to the communication bus card (124) and on to the hard drive(122) of the application-server computer via the network (45). Followingthe program instructions of the application software, the centralprocessing unit (127) accesses the extracted data and user input byretrieving it from the hard drive (122) using the random access memory(121) as computation workspace in a manner that is well known.

The computers (110, 120 and 130) shown in FIG. 3 illustratively are IBMPCs or clones or any of the more powerful computers (such as mainframecomputers) or workstations that are widely available. Typical memoryconfigurations for client personal computers (110) used with the presentinvention should include at least 512 megabytes of semiconductor randomaccess memory (111) and at least a 100 gigabyte hard drive (112).Typical memory configurations for the application-server personalcomputer (120) used with the present invention should include at least2056 megabytes of semiconductor random access memory (121) and at leasta 250 gigabyte hard drive (122). Typical memory configurations for thedatabase-server personal computer (130) used with the present inventionshould include at least 4112 megabytes of semiconductor random accessmemory (131) and at least a 500 gigabyte hard drive (132).

Using the system described above, customer financial data is analyzedbefore a comprehensive risk management program is developed andimplemented for each customer. The risk reduction program development iscompleted in two stages. As shown in FIG. 5 the first stage ofprocessing (block 200 from FIG. 1) programs bots to continually extract,aggregate, manipulate and store the data from user input, externaldatabases (25) and customer databases (30) as required. Bots areindependent components of the application that have specific tasks toperform. As shown in FIG. 6 the second stage of processing (block 300from FIG. 1) analyzes customer risk profiles, determines the optimalrisk transfer program for each customer, sets prices and communicateswith each customer as required to complete risk reduction programdevelopment and implementation. The processing described in thisapplication for identifying the optimal risk transfer program for eachcustomer can optionally be completed at the enterprise level (as shownin the cross referenced application Ser. No. 09/688,983) before data istransmitted to the system of the present invention.

System Settings and Data Bots

The flow diagrams in FIG. 5 details the processing that is completed bythe portion of the application software (200) that obtains systemssettings from the system operator (21) before extracting, aggregatingand storing the information required for system operation from a basicfinancial system database, an external database (25), and advancedfinance system database (30) and a customer database (35).

System processing starts in a block 201, FIG. 5A, which immediatelypasses processing to a software block 202. The software in block 202prompts the system operator (21) via the system settings data window(701) to provide system setting information. The system settinginformation entered by the system operator (21) is transmitted via thenetwork (45) back to the application server (120) where it is stored inthe system settings table (158) in the application database (50) in amanner that is well known. The specific inputs the system operator (21)is asked to provide at this point in processing are shown in Table 1.

TABLE 1 1. Continuous run, if yes, frequency? (hourly, daily, weekly,monthly or quarterly) 2. Account structure hierarchy 3. Metadatastandard (XML, MS OIM, MDC) 4. Location of account structure 5. Locationof basic financial system database and metadata 6. Location of advancedfinance system database and metadata 7. Location of customer database(s)and metadata 8. Location of external database(s) and metadata 9. Basecurrency 10. Asset classes of interest 11. Contingent capitalalternatives 12. Default missing data procedure 13. Maximum time to waitfor user input 14. Confidence interval for risk reduction programsThe software in block 202 uses the current system date to determine thetime periods (months) that require data to complete the development ofrisk transfer programs. After the date range is calculated, it is storedin the system settings table (158). In the preferred embodiment data isobtained for the three year period before and the three year forecastperiod after the current date. The system operator (21) also has theoption of specifying the data periods that will be used for completingsystem calculations.

After the storage of system setting data is complete, processingadvances to a software block 203. The software in block 203 prompts thesystem operator (21) via the metadata and conversion rules window (702)to map metadata using the standard previously specified by the systemoperator (21) (XML, Microsoft Open Information Model or the MetadataCoalitions specification) from the basic financial system database (5),the external database (25), the advanced financial system database (30)and the customer database (35) to the enterprise hierarchy stored in thesystem settings table (158) and to the pre-specified fields in themetadata mapping table (159). Pre-specified fields in the metadatamapping table include, the revenue, expense and capital components andsub-components for the exchange and pre-specified fields for expectedvalue drivers. Because the bulk of the information being extracted isfinancial information, the metadata mapping often takes the form ofspecifying the account number ranges that correspond to the differentfields in the metadata mapping table (159). Table 2 shows the baseaccount number structure that the account numbers in the other systemsmust align with. For example, using the structure shown below, therevenue component for the enterprise could be specified as enterprise01, any department number, accounts 400 to 499 (the revenue accountrange) with any sub-account.

TABLE 2 Account Number 01 - 902 (any) - 477- 86 (any) Segment EnterpriseDepartment Account Sub-account Subgroup Workstation Marketing RevenueSingapore Position 4 3 2 1As part of the metadata mapping process, any database fields that arenot mapped to pre-specified fields are defined by the system operator(21) as component of value, elements of value or non-relevant attributesand “mapped” in the metadata mapping table (159) to the correspondingfields in each database in a manner identical to that described abovefor the pre-specified fields. After all fields have been mapped to themetadata mapping table (159), the software in block 203 prompts thesystem operator (21) via the metadata and conversion rules window (702)to provide conversion rules for each metadata field for each datasource. Conversion rules will include information regarding currencyconversions and conversion for units of measure that may be required toaccurately and consistently analyze the data. The inputs from the systemoperator (21) regarding conversion rules are stored in the conversionrules table (160) in the application database (50). When conversionrules have been stored for all fields from every data source, thenprocessing advances to a software block 204.

The software in block 204 checks the bot date table (141) anddeactivates any basic financial system data bots with creation datesbefore the current system date and retrieves information from the systemsettings table (158), metadata mapping table (159), conversion rulestable (160), the asset position table (149) and the basic financialsystem table (161). The software in block 204 then initializes data botsfor each field in the metadata mapping table (159) that mapped to thebasic financial system database (5) in accordance with the frequencyspecified by system operator (21) in the system settings table (158).Bots are independent components of the application that have specifictasks to perform. In the case of data acquisition bots, their tasks areto extract and convert data from a specified source and then store it ina specified location. Each data bot initialized by software block 204will store its data in the asset position table (149) or the basicfinancial system table (161). Every data acquisition bot for every datasource contains the information shown in Table 3.

TABLE 3 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. The data source location 3. Mapping information 4. Timingof extraction 5. Conversion rules (if any) 6. Storage Location (to allowfor tracking of source and destination events) 7. Creation date (date,hour, minute, second)After the software in block 204 initializes all the bots for the basicfinancial system database, the bots extract and convert data inaccordance with their preprogrammed instructions in accordance with thefrequency specified by system operator (21) in the system settings table(158). As each bot extracts and converts data from the basic financialsystem database (5), processing advances to a software block 209 beforethe bot completes data storage. The software in block 209 checks thebasic financial system metadata to see if all data for all fields havebeen extracted and that there are metadata assignments for all extracteddata. If the software in block 209 finds no unmapped data fields, thenthe extracted, converted data are stored in the asset position table(149) or the basic financial system table (161). Alternatively, if thereare unmapped data fields, then processing advances to a block 211. Thesoftware in block 211 prompts the system operator (21) via the metadataand conversion rules window (702) to provide metadata and conversionrules for each new field. The information regarding the new metadata andconversion rules is stored in the metadata mapping table (159) andconversion rules table (160) while the extracted, converted data arestored in the asset position table (149) or the basic financial systemtable (161). It is worth noting at this point that the activation andoperation of bots where all the fields have been mapped to theapplication database (50) continues. Only bots with unmapped fields“wait” for user input before completing data storage. The new metadataand conversion rule information will be used the next time bots areinitialized in accordance with the frequency established by the systemoperator (21). In either event, system processing passes on to asoftware block 221.

The software in block 221 checks the bot date table (141) anddeactivates any external database data bots with creation dates beforethe current system date and retrieves information from the generic risktable (147), external database table (150), system settings table (158),metadata mapping table (159) and conversion rules table (160). Thesoftware in block 221 then initializes data bots for each field in themetadata mapping table (159) that mapped to the external database (25)in accordance with the frequency specified by system operator (21) inthe system settings table (158). Bots are independent components of theapplication that have specific tasks to perform. In the case of dataacquisition bots, their tasks are to extract and convert data from aspecified source and then store it in a specified location. Each databot initialized by software block 221 will store its data in the genericrisk table (147) or the external database table (150). After thesoftware in block 221 initializes all the bots for the advanced financesystem database, the bots extract and convert data in accordance withtheir preprogrammed instructions in accordance with the frequencyspecified by system operator (21) in the system settings table (158). Aseach bot extracts and converts data from the external database (25),processing advances to a software block 209 before the bot completesdata storage. The software in block 209 checks the advanced financesystem metadata to see if all data for all fields have been extractedand that there are metadata assignments for all extracted data. If thesoftware in block 209 finds no unmapped data fields, then the extracted,converted data are stored in the generic risk table (147) or externaldatabase table (150). Alternatively, if there are unmapped data fields,then processing advances to a block 211. The software in block 211prompts the system operator (21) via the metadata and conversion ruleswindow (702) to provide metadata and conversion rules for each newfield. The information regarding the new metadata and conversion rulesis stored in the metadata mapping table (159) and conversion rules table(160) while the extracted, converted data are stored in the generic risktable (147) or external database table (150). It is worth noting at thispoint that the activation and operation of bots where all the fieldshave been mapped to the application database (50) continues. Only botswith unmapped fields “wait” for user input before completing datastorage. The new metadata and conversion rule information will be usedthe next time bots are initialized in accordance with the frequencyestablished by the system operator (21). In either event, systemprocessing passes on to a software block 225.

The software in block 225 checks the bot date table (141) anddeactivates any advanced finance system data bots with creation datesbefore the current system date and retrieves information from the systemsettings table (158), metadata mapping table (159), conversion rulestable (160) and advanced finance system table (162). The software inblock 225 then initializes data bots for each field in the metadatamapping table (159) that mapped to the advanced finance system database(30) in accordance with the frequency specified by system operator (21)in the system settings table (158). Bots are independent components ofthe application that have specific tasks to perform. In the case of dataacquisition bots, their tasks are to extract and convert data from aspecified source and then store it in a specified location. Each databot initialized by software block 225 will store its data in the assetposition table (149) or the advanced finance system table (162). Afterthe software in block 225 initializes all the bots for the advancedfinance system database, the bots extract and convert data in accordancewith their preprogrammed instructions in accordance with the frequencyspecified by system operator (21) in the system settings table (158). Aseach bot extracts and converts data from the basic financial systemdatabase (5), processing advances to a software block 209 before the botcompletes data storage. The software in block 209 checks the advancedfinance system metadata to see if all data for all fields have beenextracted and that there are metadata assignments for all extracteddata. If the software in block 209 finds no unmapped data fields, thenthe extracted, converted data are stored in the asset position table(149) or the advanced finance system table (162). Alternatively, ifthere are unmapped data fields, then processing advances to a block 211.The software in block 211 prompts the system operator (21) via themetadata and conversion rules window (702) to provide metadata andconversion rules for each new field. The information regarding the newmetadata and conversion rules is stored in the metadata mapping table(159) and conversion rules table (160) while the extracted, converteddata are stored in asset position table (149) or the advanced financesystem table (162). It is worth noting at this point that the activationand operation of bots where all the fields have been mapped to theapplication database (50) continues. Only bots with unmapped fields“wait” for user input before completing data storage. The new metadataand conversion rule information will be used the next time bots areinitialized in accordance with the frequency established by the systemoperator (21). In either event, system processing passes on to asoftware block 226.

The software in block 226 checks the bot date table (141) anddeactivates any customer database data bots with creation dates beforethe current system date and retrieves information from the systemsettings table (158), metadata mapping table (159), conversion rulestable (160) and customer table (142). The software in block 226 theninitializes data bots for each field in the metadata mapping table (159)that mapped to the customer database (35) in accordance with thefrequency specified by system operator (21) in the system settings table(158). Bots are independent components of the application that havespecific tasks to perform. In the case of data acquisition bots, theirtasks are to extract and convert data from a specified source and thenstore it in a specified location. Each data bot initialized by softwareblock 226 will extract the model of customer financial performance byelement of value, factor and risk and the confidence interval for riskreduction programs specified by the customer. The bot will then storethis data in the customer profile table (145). After the software inblock 226 initializes all the bots for the advanced finance systemdatabase, the bots extract and convert data in accordance with theirpreprogrammed instructions in accordance with the frequency specified bysystem operator (21) in the system settings table (158). As each botextracts and converts data from the customer database (25), processingadvances to a software block 209 before the bot completes data storage.The software in block 209 checks the advanced finance system metadata tosee if all data for all fields have been extracted and that there aremetadata assignments for all extracted data. If the software in block209 finds no unmapped data fields, then the extracted, converted dataare stored in the customer profile table (145). Alternatively, if thereare unmapped data fields, then processing advances to a block 211. Thesoftware in block 211 prompts the system operator (21) via the metadataand conversion rules window (702) to provide metadata and conversionrules for each new field. The information regarding the new metadata andconversion rules is stored in the metadata mapping table (159) andconversion rules table (160) while the extracted, converted data arestored in the customer profile table (145). It is worth noting at thispoint that the activation and operation of bots where all the fieldshave been mapped to the application database (50) continues. Only botswith unmapped fields “wait” for user input before completing datastorage. The new metadata and conversion rule information will be usedthe next time bots are initialized in accordance with the frequencyestablished by the system operator (21). In either event, systemprocessing passes on to software block 301.

Risk Exchange

The flow diagram in FIG. 6 details the processing that is completed bythe portion of the application software (300) that analyzes informationfrom a number of customers and arranges for risk “swaps” and/or the saleof risk transfer products to each customer at a price that meets theprofit goals and reserve requirements of the company operating the riskexchange. The description below will follow the processing andactivities of the system described herein when one new customer profileis transmitted to the exchange.

System processing in this portion of the application software (300)begins in a block 302. The software in block 302 checks the bot datetable (141) and deactivates any transfer bots with creation dates beforethe current system date for the customer transmitting data to theexchange. The software in block 302 then retrieves the information fromthe xml profile table (140), the customer table (142), the risk productstable (143), the swaps table (144) and the customer profile table (145)as required to initialize transfer bots for the customer transmitting asummary profile to the exchange.

Bots are independent components of the application that have specifictasks to perform. In the case of transfer bots, their primary tasks areto identify swaps, existing product and new products that can be used tosatisfy the risk transfer needs of the customer transmitting data to theexchange. For example, if one customer has a significant risk from oilprices dropping (a heating oil company, for example) and anothercustomer faces a significant risk when oil prices rise (a truckingcompany, for example), then the transfer bot will identify theoffsetting risk factors and record a swap. If the risk transfer can becompleted by both an existing risk transfer product and a swap, thenpreference is given to the swap. Every transfer bot contains theinformation shown in Table 4.

TABLE 4 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Risk factor 6. Type: Swap, existingproduct or (potential) new product 7. Amount(s) 8. Date(s) 9. Customer 1(for swaps only) . . . to 9 + n. Customer n (for swaps only)After the transfer bot identifies the swaps, existing products and newproducts that will satisfy the needs of the enterprise for risk transferthe results are saved to the application database (50). Information onswaps is saved on the swaps table (144) and the customer profile table(145) and information on new products is saved in the risk productstable (143) without a price. The price for new products will beestablished later in the processing. After data storage is complete,processing advances to a software block 305.

The software in block 305 checks the bot date table (141) anddeactivates any liability scenario bots with creation dates before thecurrent system date. The software in block 305 then retrieves theinformation from the xml profile table (140), the customer table (142),the risk products table (143), the swaps table (144), the customerprofile table (145), the exchange payout history table (146), thegeneric risk table (147) and the exchange premium history table (156) asrequired to initialize new liability scenario bots. Bots are independentcomponents of the application that have specific tasks to perform. Inthe case of liability scenario bots, their primary tasks are to create aseries of scenarios estimating the net payout (premiums minus payout=netpayout) associated the risks that may be transferred via swaps orinsurance from all customers. There are two types of scenarios developedat this stage of processing, normal scenarios and extreme scenarios. Thescenarios are developed by combining the information and statistics fromsummary profiles transmitted by the customers of the exchange with theexchange payout history, the exchange premium history and generic riskinformation obtained from the external database (25). Every liabilityscenario bot activated in this block contains the information shown inTable 5.

TABLE 5 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: extreme or normalAfter the liability scenario bots are initialized, they retrieve therequired information from the xml profile table (140), the customertable (142), the risk products table (143), the swaps table (144), thecustomer profile table (145), the exchange payout history table (146),the generic risk table (147), the external database table (150), thebasic financial system table (161), the advanced finance system table(162) and the exchange premium history (156) before generating a seriesof net payout scenarios that are appropriate for the type of analysisbeing completed—extreme or normal. The bot saves the scenarios in theliability scenario table (148) in the application database (50) andprocessing advances to a block 309.

The software in block 309 continually completes analyses similar tothose completed by the analysis bots in the enterprise portion of thecross referenced application Ser. No. 10/747,471. The software in thisblock uses the publicly available information stored in the externaldatabase table (150) to complete the analyses shown in Table 6 for eachequity investment listed in the asset position table (149) and describedin data obtained from the external database (25).

TABLE 6 1. Identify market value factors causing changes in the equitymarket price; 2. Forecast the value of the current operation for thecompany as a function of the causal factors identified in 1 and priorperformance using forecasting method for revenue, expense and capitalchange similar to that described in related U.S. Pat. No. 5,615,109; 3.Forecast the allocation of industry real options to the company on thebasis of relative causal intangible element strength using forecastingmethod similar to that described in related U.S. Pat. No. 5,615,109; and4. Forecast the income (dividends) provided by the equity as a functionof the causal factors identified in 1 and prior performanceThe results of the first three forecasts (items 2, 3 and 4 from Table 6)are saved in the asset forecasts table (151) in the application database(50) and the market value factors (item 1 from Table 6) are saved withthe appropriate equity in the asset position table (149). The softwarein this block uses the publicly available information stored in theexternal database table (150) to complete the analyses shown in Table 6for each income generating investments (i.e. bonds or real estate)listed in the asset position table (149) and described in data obtainedfrom the external database (25). The software in block 309 then analyzesthe covariance between the causal factors for each of the assets todetermine the covariance between these assets under both normal andextreme conditions. The results of these analyses are then stored in theasset correlation table (152) before processing advances to a block 310.

The software in block 310 checks the bot date table (141) anddeactivates any scenario bots with creation dates before the currentsystem date. The software in block 310 then retrieves the informationfrom the asset position table (149), the external database table (150)and the asset correlation table (152) as required to initialize thescenario bots. Bots are independent components of the application thathave specific tasks to perform. In the case of scenario bots, theirprimary task is to identify likely scenarios for the evolution of thecausal market value factors. The scenario bots use information from theexternal databases to obtain forecasts for individual causal factorsbefore using the covariance information stored in the asset correlationtable (152) to develop scenarios for the other causal factors undernormal and extreme conditions. Every scenario bot activated in thisblock contains the information shown in Table 7.

TABLE 7 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: Normal or extremeAfter the scenario bots are initialized, they retrieve the requiredinformation and develop a variety of normal and extreme scenarios asdescribed previously. After the scenario bots complete theircalculations they save the resulting scenarios in the scenario table(153) in the application database (50) and processing advances to ablock 311.

The software in block 311 checks the bot date table (141) anddeactivates any net capital scenario bots with creation dates before thecurrent system date. The software in block 311 then retrieves theinformation from the liability scenario table (148), and the scenariotable (153) as required to initialize net capital scenarios bots. Botsare independent components of the application that have specific tasksto perform. In the case of net capital scenario bots, their primary taskis to run four different types of simulations for the exchange. The netcapital scenario bots run Monte Carlo simulations of the exchangefinancial performance using the two types of scenarios generated by theasset and liability scenario bots—normal and extreme. The net capitalscenario bots also run an unconstrained genetic algorithm simulationthat evolves to the most negative scenario and simulations specified byregulatory agencies. Every net capital scenario bot activated in thisblock contains the information shown in Table 8.

TABLE 8 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: Normal, extreme, geneticalgorithm or complianceAfter the net capital scenario bots are initialized, they retrieve therequired information and simulate the financial performance of the riskexchange under the different scenarios. After the net capital scenarioscomplete their calculations, the resulting forecasts are saved in theexchange simulation table (154) in the application database (50) andprocessing advances to a block 312.

The software in block 312 checks the bot date table (141) anddeactivates any asset optimization bots with creation dates before thecurrent system date. The software in block 312 then retrieves theinformation from the asset position table (149), the external databasetable (150), the asset forecasts table (151), the asset correlationtable (152), the scenario table (153), the exchange simulation table(154) and the advanced finance systems table (162) as required toinitialize asset optimization bots. Bots are independent components ofthe application that have specific tasks to perform. In the case ofasset optimization bots, their primary task is to determine the optimalmix of assets and contingent capital purchases (purchase reinsuranceand/or other contingent capital purchases, etc.) for the exchange undereach scenario using a linear programming optimization algorithm that isconstrained by any limitations imposed by regulatory requirements. Amulti-criteria optimization is also run at this stage to determine thebest mix for maximizing value under combined normal and extremescenarios. A penalty function for asset liability mismatch can be addedas required to minimize the difference between asset and liabilitylives. Other optimization algorithms can be used at this point toachieve the same result. Every asset optimization bot activated in thisblock contains the information shown in Table 9.

TABLE 9 1. Unique ID number (based on date, hour, minute, second ofcreation) 2. Creation date (date, hour, minute, second) 3. Mappinginformation 4. Storage location 5. Type: Normal, extreme or combinedAfter the asset optimization bots complete their analyses, the resultingasset and contingent capital mix for each set of scenarios and thecombined analysis is saved in the optimal exchange mix table (156) inthe application database (50) and the revised simulations are saved inthe exchange simulation table (154) before processing passes to asoftware block 313.

The software in block 313 prepares and displays the optimal mix of assetpurchases, asset sales and contingent capital purchases for the normal,extreme and combined scenario analysis using the optimal mix reviewwindow (703). The optimal mix for the normal and extreme scenarios aredetermined by calculating the weighted average sum of the differentscenarios where the weighting is determined by the relative likelihoodof the scenario. The display identifies the optimal mix from thecombined analysis as the recommended solution for exchange valuemaximization. At this point, the system operator (21) is given theoption of:

1) Editing (adding or deleting products and activities) from therecommended solution;

2) Selecting the optimal mix from the normal scenarios;

3) Selecting and then editing the optimal mix from the normal scenarios;

4) Selecting the optimal mix from the extreme scenarios;

5) Selecting and then editing the optimal mix from the extremescenarios; or

6) Leaving the default choice in place.

After the system operator (21) has finished the review and the optionaledit of the selected mix, any changes are saved in the optimal exchangemix table (156) in the application database (50) before processingadvances to a software block 314.

The software in block 314 compares the new optimal mix to the existingasset position stored in the asset position table (149) and orders aregenerated to purchase assets, sell assets and/or purchase contingentcapital as required to bring the current asset position in line with thenew optimal mix. These orders are then transmitted via a network (45) toother institutions and exchanges on the Internet (40). When the orderconfirmations are received, the asset position table (149) is updatedwith the new information and processing advances to a block 315. It isworth noting at this point that the processing described for theprevious blocks in this section (302, 305, 109, 310, 311, 312, 313 and314) could also be used to manage an investment portfolio on a standalone basis.

The software in block 315 prepares and displays the proposed prices forthe risk transfer products and the swaps that are going to be offered tothe customer using the price review window (704). The list prices fromthe risk products table (143) are used for the existing risk products.Pricing for swaps are calculated by marking up the cost of the swap by astandard percentage. The software in block 315 marks up the calculatedbreakeven price for any new risk transfer products that were proposed bythe bots in block 302. At this point, the system operator (21) is giventhe option of:

1) Editing the recommended prices for any and all of the risktransfers—swaps, existing products and new products;

2) Accepting the recommended prices; or

3) Removing some of swaps and/or risk transfer products from the list.

After the system operator (21) completes the review, all price changesand the prices for any new risk transfer products are saved in the riskproducts table (143) before processing advances to a block 316.

The software in block 316 continually runs an analysis to define theoptimal risk reduction strategy for the normal and extreme scenarios foreach customer. It does this by first retrieving data from the xmlprofile table (140), the customer table (142), the risk products table(143), the swaps table (144), the customer profile table (145), theexchange payout history table (146), the generic risk table (147), theexternal database table (150) and the scenario table (153)—theinformation required to initialize the optimization algorithm. Thesoftware in the block uses a linear program that uses the financialmodel for each customer under the range of conditions expected for eachscenario to determine the optimal risk transfer program (swaps,derivative purchases, insurance purchases, etc.) within the specifiedconfidence interval (the confidence interval specified by the systemoperator (21) is used if the customer has not specified a confidenceinterval). A multi criteria optimization determines the best mix forreducing the risk under a combined normal and extreme scenario. Otheroptimization algorithms and simulations can be used at this point to thesame effect. The optimizations consider the effect of changes in thecost of capital on the optimal risk transfer solution. The resulting mixof product purchases and swaps for each scenario (normal and extreme)and the combined analysis is saved in the customer profile table (145)in the application database (50) before processing passes to a softwareblock 317. The shadow prices from these optimizations are also stored inthe risk products table (143) for use in identifying new risk reductionproducts that the system operator (21) may choose to offer at a laterdate. This information can also be used to modify pricing by customer.

The software in block 317 uses the customer interface window (705) todisplay the information regarding the optimal risk transfer program forthe customer and the pricing for the products and swaps that will beused to transfer the risks identified in the optimal risk transferprogram. This information could optionally be transmitted to thecustomer in a summary xml format that is similar to the one initiallytransmitted to the exchange by the customer. The customer (20) canreject, edit and/or accept the proposed mix of products and swaps thatare displayed. The software in block 317 accepts and confirms orders,updates the information contained in the risk products table (143), theswaps table (144), the customer profile table (145) and the exchangepremium history table (157) to reflect the accepted and confirmedorders. The software in block 317 also accepts input from the customer(20) regarding any new losses that the customer may have experienced.The software in block 317 verifies the loss is for an insured risk,updates the customer profile table (145), updates the exchange payouthistory table (146) and arranges for payment of the claim in a mannerthat is well known. This processing is continues until the customer (20)indicates that the session is complete. System processing advances to asoftware block 318.

The software in block 318 checks the system settings table (158) todetermine if the system (100) is operating in continuous mode. If thesystem is operating in a continuous mode, then processing returns toblock 205 and the processing described above is repeated. Alternatively,if the system is not operating in continuous mode, then processingadvances to a software block 320 and stops.

Thus, the reader will see that the system and method described abovetransforms extracted transaction data, corporate information,information from external databases and information from the internetinto detailed risk analyses and risk transfer programs specificallytailored to each customer using the system. The level of detail, breadthand speed of the risk analysis allows customers and managers of thesystem to manage their risks in a fashion that is superior to the methodcurrently available to users of existing risk analysis systems andtraditional insurance products.

Because the profiles used in the system (100) provide a comprehensivepicture of the financial status of the companies transferring riskthrough the exchange, the system and method described herein can be usedwith essentially no modifications to provide an on-line transfer systemfor:

1. Foreign exchange;

2. Capital (aka liquidity);

3. Any combination of foreign exchange, capital and risk.

The system described herein could be used to manage transfers ofownership rights alone or in combination with foreign exchange,liquidity and risk.

While the above description contains many specificity's, these shouldnot be construed as limitations on the scope of the invention, butrather as an exemplification of one preferred embodiment thereof.Accordingly, the scope of the invention should be determined not by theembodiment illustrated, but by the appended claims and their legalequivalents.

1. A computer implemented risk transfer method, comprising: integrate a plurality of transaction data from a plurality of management systems for a plurality of clients in accordance with a common schema, analyze said data with a series of models as required to quantity a value impact and a risk for one or more elements of value and one or more market value factors for each of one or more segments of value for each of a plurality of customers, analyzing said data to identify an optimal set of risk transfer transactions for each customer where the optimal set of risk transfer transactions is the set that minimizes the value impact of retained risks within the constraints on risk transfer imposed by the capital available for risk transfer purchases under a scenario selected from the group consisting of normal, extreme and combinations thereof, and optionally implement an optimal set of risk transfer transactions for one or more customers where risk transfer transactions are selected from the group consisting of a swap of an element of value risk, a swap of an external factor risk and combinations thereof for one or more segments of value.
 2. The method of claim 1, wherein the elements of value are selected from the group consisting of alliances, brands, channels, customers, customer relationships, employees, equipment, partnerships, processes, securities, supply chains, vendors, vendor relationships and combinations thereof.
 3. The method of claim 1, wherein the market value factors are selected from the group consisting of commodity prices, inflation rate, gross domestic product, volatility, interest rates, insider trading, consumer confidence, organization performance against expectations, the unemployment rate and combinations thereof.
 4. The method of claim 1, wherein the where risks are selected from the group consisting of event risks, contingent liabilities, variability risks, volatility risks and combinations thereof.
 5. The method of claim 4, wherein contingent liabilities are quantified using a real option algorithm.
 6. The method of claim 1, wherein analyzing data with a series of models, comprises: using a designated schema classification for each of one or more data records in each system as an aspect of financial performance data record, an element of value data record or a market value factor data record based on a user input or a system origin; generating a plurality of indicators from said element of value and external factor data, receiving said data and indicators as a first input data into a plurality of initial predictive models for each aspect of financial performance and developing an initial model configuration by selecting a data set for the element of value and external factor data variables from the plurality of predictive models using a variable selection algorithm after a training of each predictive model type is completed; testing the first input data set for independence and adjusting the schema classification structure for said data set as required to produce accurate results, receiving the tested input data set as an input into a second, induction model stage to develop an improvement to said initial model configuration as an output; receiving said second model stage output as an input into a third predictive model stage to develop and output a final predictive model; and using the final predictive model to quantify a value impact for each element of value and to simulate a financial performance in order to quantify each of one or more risks where the aspects of financial performance are revenue, expense, capital change, a derivative segment of value, an excess financial asset segment of value, a market sentiment segment of value and combinations thereof.
 7. A computer readable medium having sequences of instructions stored therein, which when executed causes a processor in at least one computer to perform risk transfer method, comprising: integrate a plurality of transaction data from a plurality of management systems for a plurality of clients in accordance with a common schema, analyze said data with a series of models as required to quantity a value impact and a risk for one or more elements of value and one or more market value factors for each of one or more segments of value for each of a plurality of customers, analyzing said data to identify an optimal set of risk transfer transactions for each customer where the optimal set of risk transfer transactions is the set that minimizes the value impact of retained risks within the constraints on risk transfer imposed by the capital available for risk transfer purchases under a scenario selected from the group consisting of normal, extreme and combinations thereof, and optionally implement an optimal set of risk transfer transactions for one or more customers where risk transfer transactions are selected from the group consisting of a swap of an element of value risk, a swap of an external factor risk, and combinations thereof for one or more segments of value, and where the segments of value are a current operation, a real option segment and segments of value selected from the group consisting of derivatives, excess financial assets, market sentiment and combinations thereof.
 8. The computer readable medium of claim 7, wherein the elements of value are selected from the group consisting of alliances, brands, channels, customers, customer relationships, employees, equipment, partnerships, processes, securities, supply chains, vendors, vendor relationships and combinations thereof.
 9. The computer readable medium of claim 7, wherein the market value factors are selected from the group consisting of commodity prices, inflation rate, gross domestic product, volatility, interest rates, insider trading, consumer confidence, organization performance against expectations, the unemployment rate and combinations thereof.
 10. The computer readable medium of claim 7, wherein the risks are selected from the group consisting of event risks, contingent liabilities, variability risks, volatility risks and combinations thereof.
 11. The computer readable medium of claim 10, wherein the contingent liabilities are quantified using a real option algorithm.
 12. The computer readable medium of claim 7, wherein analyzing data with a series of models, comprises: using a designated schema classification for each of one or more data records in each system as an aspect of financial performance data record, an element of value data record or a market value factor data record based on a user input or a system origin; generating a plurality of indicators from said element of value and external factor data, receiving said data and indicators as a first input data into a plurality of initial predictive models for each aspect of financial performance and developing an initial model configuration by selecting a data set for the element of value and external factor data variables from the plurality of predictive models using a variable selection algorithm after a training of each predictive model type is completed; testing the first input data set for independence and adjusting the schema classification structure for said data set as required to produce accurate results, receiving the tested input data set as an input into a second, induction model stage to develop an improvement to said initial model configuration as an output; receiving said second model stage output as an input into a third predictive model stage to develop and output a final predictive model; and using the final predictive model to quantify a value impact for each element of value and to simulate a financial performance in order to quantify each of one or more risks, where the aspects of financial performance are revenue, expense, capital change, a derivative segment of value, an excess financial asset segment of value, a market sentiment segment of value and combinations thereof.
 13. An enterprise system, comprising a computer with a processor having circuitry to execute instructions; a storage device available to said processor with sequences of instructions stored therein, which when executed cause the processor to: integrate a plurality of transaction data from a plurality of management systems for a plurality of clients in accordance with a common schema, analyze said data with a series of models as required to quantity a value impact and a risk for one or more elements of value and one or more market value factors for each of one or more segments of value for each of a plurality of customers, analyzing said data to identify an optimal set of risk transfer transactions for each customer where the optimal set of risk transfer transactions is the set that minimizes the value impact of retained risks within the constraints on risk transfer imposed by the capital available for risk transfer purchases under a scenario selected from the group consisting of normal, extreme and combinations thereof, and optionally implement an optimal set of risk transfer transactions for one or more customers where risk transfer transactions are selected from the group consisting of a swap of an element of value risk, a swap of an external factor risk and combinations thereof for one or more segments of value, and where the segments of value are a current operation, a derivative segment, a real option segment and segments of value selected from the group consisting of excess financial assets, market sentiment and combinations thereof.
 14. The system of claim 13, wherein the elements of value are selected from the group consisting of alliances, brands, channels, customers, customer relationships, employees, equipment, partnerships, processes, securities, supply chains, vendors, vendor relationships and combinations thereof.
 15. The system of claim 13, wherein the market value factors are selected from the group consisting of commodity prices, inflation rate, gross domestic product, volatility, interest rates, insider trading, consumer confidence, organization performance against expectations, the unemployment rate and combinations thereof.
 16. The system of claim 13, wherein the where risks are selected from the group consisting of event risks, contingent liabilities, variability risks, volatility risks and combinations thereof.
 17. The system of claim 16, wherein the contingent liabilities are quantified using a real option algorithm
 18. The system of claim 13, wherein analyzing data with a series of models, comprises: using a designated schema classification for each of one or more data records in each system as an aspect of financial performance data record, an element of value data record or a market value factor data record based on a user input or a system origin; generating a plurality of indicators from said element of value and external factor data, receiving said data and indicators as a first input data into a plurality of initial predictive models for each aspect of financial performance and developing an initial model configuration by selecting a data set for the element of value and external factor data variables from the plurality of predictive models using a variable selection algorithm after a training of each predictive model type is completed; testing the first input data set for independence and adjusting the schema classification structure for said data set as required to produce accurate results, receiving the tested input data set as an input into a second, induction model stage to develop an improvement to said initial model configuration as an output; receiving said second model stage output as an input into a third predictive model stage to develop and output a final predictive model; and using the final predictive model to quantify a value impact for each element of value and to simulate a financial performance in order to quantify each of one or more risks, where the aspects of financial performance are revenue, expense, capital change, a derivative segment of value, an excess financial asset segment of value, a market sentiment segment of value and combinations thereof. 